Scheduling execution contexts with critical regions

ABSTRACT

A scheduler in a process of a computer system detects an execution context that blocked from outside of the scheduler while in a critical region. The scheduler ensures that the execution context resumes execution on the processing resource of the scheduler on which the execution context blocked when the execution context becomes unblocked. The scheduler also prevents another execution context from entering a critical region on the processing resource prior to the blocked execution context becoming unblocked and exiting the critical region.

BACKGROUND

Processes executed in a computer system may include execution contextschedulers that schedule tasks of processes for execution in thecomputer system. A scheduler may create execution contexts (e.g.,threads, fibers, or child processes) in order to execute tasks. Duringexecution, the scheduler maintains control over these execution contextsand maintains control of the processing resources allocated to thescheduler.

At times, an execution context may be blocked by an entity other thanthe scheduler while executing on a processing resource of the scheduler.If the scheduler is not notified of the block, the processing resourcethat was executing the block execution context may become idle. Inaddition, the scheduler may undesirably attempt to schedule theexecution context on a different processing resource when the executioncontext becomes unblocked.

SUMMARY

This summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used to limit the scope of the claimed subject matter.

A scheduler in a process of a computer system detects an executioncontext that blocked from outside of the scheduler while in a criticalregion. The scheduler ensures that the execution context resumesexecution on the processing resource of the scheduler on which theexecution context blocked when the execution context becomes unblocked.The scheduler also prevents another execution context from entering acritical region on the processing resource prior to the blockedexecution context becoming unblocked and exiting the critical region.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings are included to provide a furtherunderstanding of embodiments and are incorporated in and constitute apart of this specification. The drawings illustrate embodiments andtogether with the description serve to explain principles ofembodiments. Other embodiments and many of the intended advantages ofembodiments will be readily appreciated as they become better understoodby reference to the following detailed description. The elements of thedrawings are not necessarily to scale relative to each other. Likereference numerals designate corresponding similar parts.

FIG. 1 is a block diagram illustrating an embodiment of a schedulerconfigured to schedule execution contexts for execution by processingresources.

FIGS. 2A-2C are block diagrams illustrating embodiments of a processingresource that executes execution contexts.

FIG. 3 is a flow chart illustrating an embodiment of a method forexecuting an execution context with a critical region.

FIG. 4 is a block diagram illustrating an embodiment of a schedulinggroup for use in a scheduler.

FIG. 5 is a block diagram illustrating an embodiment of a computersystem configured to implement a runtime environment including ascheduler configured to schedule execution contexts for execution byprocessing resources.

DETAILED DESCRIPTION

In the following Detailed Description, reference is made to theaccompanying drawings, which form a part hereof, and in which is shown,by way of illustration, specific embodiments in which the invention maybe practiced. In this regard, directional terminology, such as “top,”“bottom,” “front,” “back,” “leading,” “trailing,” etc., is used withreference to the orientation of the Figure(s) being described. Becausecomponents of embodiments can be positioned in a number of differentorientations, the directional terminology is used for purposes ofillustration and is in no way limiting. It is to be understood thatother embodiments may be utilized and structural or logical changes maybe made without departing from the scope of the present invention. Thefollowing detailed description, therefore, is not to be taken in alimiting sense, and the scope of the present invention is defined by theappended claims.

It is to be understood that the features of the various exemplaryembodiments described herein may be combined with each other, unlessspecifically noted otherwise.

FIG. 1 is a block diagram illustrating an embodiment of a scheduler 22in a process 12 of a runtime environment 10. Scheduler 22 is configuredto schedule execution contexts for execution by processing resources.

Runtime environment 10 represents a runtime mode of operation in acomputer system, such as a computer system 100 shown in FIG. 5 anddescribed in additional detail below, where the computer system isexecuting instructions. The computer system generates runtimeenvironment 10 from a runtime platform such as a runtime platform 122shown in FIG. 5 and described in additional detail below.

Runtime environment 10 includes an least one invoked process 12, aresource management layer 14, and a set of hardware threads 16(1)-16(M),where M is an integer that is greater than or equal to one and denotesthe Mth hardware thread 16(M). Runtime environment 10 allows tasks fromprocess 12 to be executed, along with tasks from any other processesthat co-exist with process 12 (not shown), using an operating system(OS) such as an OS 120 shown in FIG. 5 and described in additionaldetail below, resource management layer 14, and hardware threads16(1)-16(M). Runtime environment 10 operates in conjunction with the OSand/or resource management layer 14 to allow process 12 to obtainprocessor and other resources of the computer system (e.g., hardwarethreads 16(1)-16(M)).

Runtime environment 10 includes a scheduler function that generatesscheduler 22. In one embodiment, the scheduler function is implementedas a scheduler application programming interface (API). In otherembodiments, the scheduler function may be implemented using othersuitable programming constructs. When invoked, the scheduler functioncreates scheduler 22 in process 12 where scheduler 22 operates toschedule tasks of process 12 for execution by one or more hardwarethreads 16(1)-16(M). Runtime environment 10 may exploit fine grainedconcurrency that application or library developers express in theirprograms (e.g., process 12) using accompanying tools that are aware ofthe facilities that the scheduler function provides.

Process 12 includes an allocation of processing and other resources thathosts one or more execution contexts (viz., threads). Process 12 obtainsaccess to the processing and other resources in the computer system(e.g., hardware threads 16(1)-16(M)) from the OS and/or resourcemanagement layer 14. Process 12 causes tasks to be executed using theprocessing and other resources.

Process 12 generates work in tasks of variable length where each task isassociated with an execution context in scheduler 22. Each task includesa sequence of instructions that perform a unit of work when executed bythe computer system. Each execution context forms a thread that executesassociated tasks on allocated processing resources. Each executioncontext includes program state and machine state information. Executioncontexts may terminate when there are no more tasks left to execute. Foreach task, runtime environment 10 and/or process 12 either assign thetask to scheduler 22 to be scheduled for execution or otherwise causethe task to be executed without using scheduler 22.

Process 12 may be configured to operate in a computer system based onany suitable execution model, such as a stack model or an interpretermodel, and may represent any suitable type of code, such as anapplication, a library function, or an operating system service. Process12 has a program state and machine state associated with a set ofallocated resources that include a defined memory address space. Process12 executes autonomously or substantially autonomously from anyco-existing processes in runtime environment 10. Accordingly, process 12does not adversely alter the program state of co-existing processes orthe machine state of any resources allocated to co-existing processes.Similarly, co-existing processes do not adversely alter the programstate of process 12 or the machine state of any resources allocated toprocess 12.

Resource management layer 14 allocates processing resources to process12 by assigning one or more hardware threads 16 to process 12. Resourcemanagement layer 14 exists separately from the OS in the embodiment ofFIG. 1. In other embodiments, resource management layer 14 or some orall of the functions thereof may be included in the OS.

Hardware threads 16 reside in execution cores of a set or one or moreprocessor packages (e.g., processor packages 102 shown in FIG. 5 anddescribed in additional detail below) of the computer system. Eachhardware thread 16 is configured to execute instructions independentlyor substantially independently from the other execution cores andincludes a machine state. Hardware threads 16 may be included in asingle processor package or may be distributed across multiple processorpackages. Each execution core in a processor package may include one ormore hardware threads 16.

Process 12 implicitly or explicitly causes scheduler 22 to be createdvia the scheduler function provided by runtime environment 10. Schedulerinstance 22 may be implicitly created when process 12 uses APIsavailable in the computer system or programming language features. Inresponse to the API or programming language features, runtimeenvironment 10 creates scheduler 22 with a default policy. To explicitlycreate a scheduler 22, process 12 may invoke the scheduler functionprovided by runtime environment 10 and specify one or more policies forscheduler 22.

Scheduler 22 interacts with resource management layer 14 to negotiateprocessing and other resources of the computer system in a manner thatis transparent to process 12. Resource management layer 14 allocateshardware threads 16 to scheduler 22 based on supply and demand and anypolicies of scheduler 22.

In the embodiment shown in FIG. 1, scheduler 22 manages the processingresources by creating virtual processors 32 that form an abstraction ofunderlying hardware threads 16. Scheduler 22 includes a set of virtualprocessors 32(1)-32(N) where N is an integer greater than or equal toone and denotes the Nth virtual processor 32(N). Scheduler 22multiplexes virtual processors 32 onto hardware threads 16 by mappingeach virtual processor 32 to a hardware thread 16. Scheduler 22 may mapmore than one virtual processor 32 onto a particular hardware thread 16but maps only one hardware thread 16 to each virtual processor 32. Inother embodiments, scheduler 22 manages processing resources in othersuitable ways to cause instructions of process 12 to be executed byhardware threads 16.

The set of execution contexts in scheduler 22 includes a set ofexecution contexts 34(1)-34(N) with respective, associated tasks36(1)-36(N) that are being executed by respective virtual processors32(1)-32(N) and, at any point during the execution of process 12, a setof zero or more execution contexts 38. Each execution context 34 and 38includes state information that indicates whether an execution context34 or 38 is executing, runnable (e.g., in response to becoming unblockedor added to scheduler 22), or blocked. Execution contexts 34 that areexecuting have been attached to a virtual processor 32 and are currentlyexecuting. Execution contexts 38 that are runnable include an associatedtask 40 and are ready to be executed by an available virtual processor32. Execution contexts 38 that are blocked also include an associatedtask 40 and are waiting for data, a message, or an event that is beinggenerated by another execution context 34 or will be generated byanother execution context 38.

Each execution context 34 executing on a virtual processor 32 maygenerate, in the course of its execution, additional tasks 42, which areorganized in any suitable way (e.g., added to work queues (not shown inFIG. 1)). Work may be created by using either application programminginterfaces (APIs) provided by runtime environment 10 or programminglanguage features and corresponding tools in one embodiment. Whenprocessing resources are available to scheduler 22, tasks are assignedto execution contexts 34 or 38 that execute them to completion onvirtual processors 32 before picking up new tasks. An execution context34 executing on a virtual processor 32 may also unblock other executioncontexts 38 by generating data, a message, or an event that will be usedby other execution contexts 38.

Each task in scheduler 22 may be realized (e.g., realized tasks 36 and40), which indicates that an execution context 34 or 38 has been or willbe attached to the task and the task is ready to execute. Realized taskstypically include unblocked execution contexts and scheduled agents. Atask that is not realized is termed unrealized. Unrealized tasks (e.g.,tasks 42) may be created as child tasks generated by the execution ofparent tasks and may be generated by parallel constructs (e.g., parallelor parallel for). Scheduler 22 may be organized into a synchronizedcollection (e.g., a stack and/or a queue) for logically independenttasks with execution contexts (i.e., realized tasks) along with a listof workstealing queues for dependent tasks (i.e., unrealized tasks) asillustrated in the embodiment of FIG. 4 described below.

Prior to executing tasks, scheduler 22 obtains execution contexts 34 and38 from runtime environment 10 or the operating system. Availablevirtual processors 32 locate and execute execution contexts 34 to beginexecuting tasks. Virtual processors 32 become available again inresponse to an execution context 34 completing, blocking, or otherwisebeing interrupted (e.g., explicit yielding or forced preemption). Whenvirtual processors 32 become available, the available virtual processor32 may switch to a runnable execution context 38 to execute anassociated task 40. The available virtual processor 32 may also executea next task 40 or 42 as a continuation on a current execution context 34if the previous task 36 executed by the current execution context 34completed.

Scheduler 22 searches for a runnable execution context 38 or anunrealized task 42 to attach to the available virtual processor 32 forexecution in any suitable way. For example, scheduler 22 may search fora runnable execution context 38 to execute before searching for anunrealized task 42 to execute. Scheduler 22 continues attachingexecution contexts 38 to available virtual processors 32 for executionuntil all tasks and execution contexts 38 of scheduler 22 have beenexecuted.

At times, an execution context 34 may be blocked by an entity other thanscheduler 22. The entity may be the OS or a runtime platform, such as aruntime platform 122 shown in FIG. 5 and described in additional detailbelow, and may preempt an execution context 34 without notifyingscheduler 22. Such preemption may occur, for example, if executioncontext 34 performs a memory access that triggers a page fault in asystem where the OS supports demand-paged virtual memory. If anexecution context 34 page faults in such a system, the OS may preemptand block the execution context 34 and service the page fault as a hardfault that requires input/output (I/O) to a device, such as a hard diskdrive in memory system.

In some circumstances, an execution context 34 that is blocked fromoutside of scheduler 22 may simply be rescheduled by scheduler 22 whenscheduler 22 detects that the execution context 34 has become unblocked.Scheduler 22 may rescheduled the execution context 34 by attaching theexecution context 34 to a virtual processor 32 that may or may not bethe same virtual processor 32 that was executing the execution context34 when the execution context 34 was blocked.

In other circumstances, however, an execution context 34 that is blockedfrom outside of scheduler 22 may be accessing data corresponding to aparticular processing resource. For example, the execution context 34may hold locks or other synchronization mechanisms (e.g., schedulinglocks) or may be otherwise accessing data corresponding to a particularprocessing resource when the execution context 34 is blocked. As aresult, a subsequent execution context 34 that is scheduled on thevirtual processor 32 that was executing the blocked execution context 34may not be able to execute because of the locks held by the blockedexecution context 34. In addition, data accessed by the blockedexecution context 34 may have relevance only on the virtual processor 32that was executing the blocked execution context 34. As a result, theexecution of the blocked execution context 34 may become confused ifscheduler 22 reschedules the blocked execution context 34 on anothervirtual processor 32 when the execution context 34 becomes unblocked.

Scheduler 22 operates to detect each execution context 34 that isblocked from outside of scheduler 22 while in a critical region 50(e.g., critical region 50A in FIG. 2A) of the execution context 34. Acritical region 50 is a set of instructions in an execution context 34whose execution becomes contingent on data corresponding to a particularprocessing resource, e.g., a particular virtual processor 32. Whenscheduler 22 detects such an execution context 34, scheduler 22 ensuresthat the execution context 34 resumes execution on the processingresource, e.g., the virtual processor 32, on which the execution context34 blocked when the execution context 34 becomes unblocked. Scheduleralso prevents another execution context 34 or 38 from entering acritical region 50 on the same processing resource, e.g., the samevirtual processor 32, prior to the blocked execution context 34 becomingunblocked and exiting the critical region 50.

In one embodiment, a critical region 50 may encompass code that isresponsible for making a scheduling decision for a virtual processor 32.The scheduling decision may involve identifying an execution context 38with accompanying task or a task 42 to be picked up for execution by thevirtual processor 32. In making the scheduling decision, the code in thecritical region 50 may take locks or initiate other synchronizationmechanisms that are local to the virtual processor 32. In otherembodiments, a critical region 50 may encompass code that performs otherfunctions where it is desirable to ensure that the code, if blocked fromoutside of scheduler 22, resumes on the same virtual processor 32.

FIG. 2A is a block diagram illustrating an embodiment of a processingresource, i.e., virtual processor 32, executing an execution context34A. Execution context 34A includes a critical region 50A which, in theembodiment of FIG. 2A, is defined by programming constructs 52A(EnterCriticalRegion) and 54A (ExitCriticalRegion). In one embodiment,constructs 52A and 54A are implemented as APIs to functions in resourcemanagement layer 14, the OS, and/or the runtime platform. In otherembodiments, constructs 52A and 54A may be implemented using othersuitable type and/or number of explicit programming constructs. In otherembodiments, critical regions 50 may be defined implicitly by includingselected types of instructions or other constructs that, by definition,cause a portion of an execution context 34 to be a critical region 50.

When an execution context 34 enters or otherwise begins execution of acritical region 50, the execution context 34 sets a critical regionindicator 56 (e.g., critical region indicator 56A in FIG. 2A)corresponding to the execution context 34. The execution context 34clears the critical region indicator 56 when the execution context 34exits or otherwise finishes execution of the critical region 50. Inaddition, an execution context 34 stores a virtual processor indicator58 (e.g., virtual processor indicator 58A in FIG. 2A) that identifiesthe virtual processor 32 on which the critical region 50 is executing.

In one embodiment, each critical region indicator 56 forms a counterthat is incremented when a corresponding execution context 34 enterseach critical region 50 and is decremented when the correspondingexecution context 34 exits each critical region 50. In otherembodiments, each critical region indicator 56 forms another suitableindicator that identifies when a corresponding execution context 34 isexecuting a critical region 50 or is blocked during execution of acritical region 50.

Scheduler 22 identifies each execution context 34 that blocked in acritical region 50 using a corresponding critical region indicator 56and a corresponding virtual processor indicator 58 as illustrated by themethod of FIG. 3. FIG. 3 is a flow chart illustrating an embodiment of amethod for executing an execution context 34 with a critical region 50.The method of FIG. 3 will be described with reference to FIGS. 2A-2Cwhich are block diagrams illustrating embodiments of a processingresource, i.e., virtual processor 32, that executes execution contexts34A and 34B.

In FIG. 3, a determination is made as to whether critical region 50A ofexecution context 34A is to be entered as indicated in a block 62. Thedetermination may be made explicitly in response to executing construct52A in one embodiment or implicitly in other embodiments. Criticalregion 50A may, for example, include code that allows virtual processor32 to make a scheduling decision as to which execution context 38 ortask 42 to execute next.

When an entry to critical region 50A is detected, a determination ismade as to whether the virtual processor 32 that is executing theexecution context 34A is available to execute the critical region 50A asindicated in a block 64. Scheduler 22 prevents the execution context 34Afrom entering critical region 50A if another execution context 34 or 38is currently blocked and the execution context 34 or 38 blocked in acritical region 50 while executing on the same virtual processor 32 thatis executing execution context 34A. In such a scenario, the virtualprocessor 32 is not available to execute critical region 50A ofexecution context 34A and scheduler 22 prevents critical region 50A fromexecuting on the virtual processor 32 as indicated in a block 66. To doso, scheduler 22 may block execution context 34A prior to enteringcritical region 50A or may move execution context 34A to another virtualprocessor 32 prior to entering critical region 50A.

If no other execution context 34 or 38 is currently blocked whileexecuting a critical region 50 on the virtual processor 32, executioncontext 34A enters critical region 50A and sets critical regionindicator 56A as indicated in block 68. In one embodiment, executioncontext 34A increments critical region indicator 56A to set criticalregion indicator 56A. In other embodiments, execution context 34A setscritical region indicator 56A in other suitable ways.

A determination is made as to whether execution context 34A is blockedfrom outside of scheduler 22 prior to exiting critical region 50A asindicated blocks 70 and 72. If execution context 34A exits criticalregion 50A prior to being blocked, then execution context 34A clearscritical region indicator 56A as indicated in a block 74. Thedetermination that execution context 34A exited critical region 50A maybe made explicitly in response to executing construct 54A in oneembodiment or implicitly in other embodiments. In one embodiment,execution context 34A decrements critical region indicator 56A to clearcritical region indicator 56A. In other embodiments, execution context34A clears critical region indicator 56A in other suitable ways.

If execution context 34A is blocked from outside scheduler 22 prior toexiting critical region 50A, then execution context 34A blocks andstores a virtual processor indicator 58A that identifies the virtualprocessor 32 on which the critical region 50A is executing as indicatedin block 76. Critical region 50A may invoke a page fault, for example,which causes the OS to block critical region 50A so that the page faultcan be serviced. Execution context 34A remains in the blocked stateuntil the entity that causes the block provides a signal to scheduler 22that indicates that execution context 34A has become unblocked asindicated in a block 78.

When execution context 34A becomes unblocked, scheduler 22 examinescritical region indicator 56A to detects that execution context 34A wasblocked while in critical region 50A. Scheduler 22 also examines virtualprocessor indicator 58A to identify the virtual processor 32 that wasexecuting critical region 50A when execution context 34A was blocked.Scheduler 22 causes the virtual processor 32 to switch to executioncontext 34A to continue executing critical region 50A as indicated in ablock 80. When the virtual processor 32 becomes available, scheduler 22may switch to the unblocked execution context 34A before switching toother execution contexts 38 or tasks 42.

Subsequent to execution context 34A blocking and prior to resumingexecution context 34A on the virtual processor 32, scheduler 22 maycause virtual processor 32 to switch to an execution context 34B asshown in FIG. 2B and perform the method of FIG. 3 separately forexecution context 34B. In FIG. 2B, virtual processor 32 is executingexecution context 34B while execution context 34A is blocked. Ifexecution context 34B executes to completion without attempting to entera critical region 50B, then virtual processor 32 may switch to andexecute other execution contexts prior to resuming execution context34A. If, however, execution context 34B attempts to enter a criticalregion 50B, scheduler 22 prevents critical region 50B from executing onthe virtual processor 32, as described above in blocks 64 and 66,because execution context 34A blocked on the same virtual processor 32in critical region 50A. Scheduler 22 may block execution context 34Bprior to entering critical region 50B or may move execution context 34Bto another virtual processor 32 prior to entering critical region 50B.

Once the execution of critical region 50A of execution context 34A isresumed, execution context 34A maintains the state of critical regionindicator 56A until critical region 50A is exited. In FIG. 2C, virtualprocessor 32 resumes the execution of critical region 50A. Executioncontext 34B is shown as blocked in FIG. 2C where the blocking may haveoccurred because execution context 34B attempted to enter criticalregion 50B. Upon exit of critical region 50A, execution context 34Aclears critical region indicator 56A as indicated in block 74.

With the method of FIG. 3, scheduler 22 allows execution context 34A tobe resumed subsequent to being preempted by an entity other thanscheduler 22 and without providing any knowledge of the preemption toexecution context 34A.

In embodiments of runtime environment 10 that include garbagecollection, scheduler 22 may operate to suspend execution contexts 34and 38 at a safe point in response to garbage collection being invoked.To get each execution context 34 and 38 to a safe point, scheduler 22round robins through execution contexts 34 or 38 to allow each executioncontext 34 and 38 to reach a safe point. As shown in the embodiment ofFIG. 3, any execution context 34 or 38 that attempts to enter a criticalregion 50 while trying to reach a safe point ensures that the virtualprocessor 32 that is executing the execution context 34 or 38 isavailable to enter the critical region 50. If not, then the executioncontext 34 or 38 cooperatively blocks prior to entering the criticalregion 50 to reach the safe point.

The above embodiments may allow a cooperative scheduler to operate in aruntime environment where preemptive blocking of an execution of anexecution context of the scheduler can occur without knowledge of thescheduler. When such blocking occurs in a critical region of theexecution context, the scheduler invokes mechanisms that ensure thedesired execution of the execution context when the execution context isunblocked. In addition, the execution contexts may be structured tooperate with a cooperative scheduler without regard for the possibilityof preemptive blocking.

In one embodiment, process 12 (shown in FIG. 1) organizes tasks into oneor more schedule groups 90 and presents schedule groups 90 to scheduler22 as shown in FIG. 4. FIG. 4 is a block diagram illustrating anembodiment of a schedule group 90 for use in scheduler 22.

Schedule group 90 includes a runnables collection 92, a realized taskcollection 93, a work collection 94, and a set of zero or moreworkstealing queues 96. Runnables collection 92 contains a list ofunblocked execution contexts 38. Scheduler 22 adds an execution context38 to runnables collection 92 when an execution context becomesunblocked. Realized task collection 93 contains a list of realized tasks40 (e.g., unstarted agents) that may or may not have associatedexecution contexts 38. Scheduler 22 adds a realized task to realizedtask collection 93 when a new runnable task is presented to scheduler 22by process 12. Work collection 94 contains a list of workstealing queues96 as indicated by an arrow 98 and tracks the execution contexts 34 thatare executing tasks from the workstealing queues 96. Each workstealingqueue 96 includes one or more unrealized tasks 42.

Using the embodiment of FIG. 4, scheduler 22 may first search forunblocked execution contexts 38 in the runnables collection 92 of eachschedule group 90 in scheduler 22. Scheduler 22 may then search forrealized tasks in the realized task collection 93 of all schedule groups90 in scheduler 22 before searching for unrealized tasks in theworkstealing queues 96 of the schedule groups 90.

In one embodiment, a virtual processor 32 that becomes available mayattempt to locate a runnable execution context 38 in the runnablescollection 92 in the schedule group 90 from which the available virtualprocessor 32 most recently obtained a runnable execution context 38(i.e., the current schedule group 90). The available virtual processor32 may then attempt to locate a runnable execution context 38 in therunnables collections 92 in the remaining schedule groups 90 ofscheduler 22 in a round-robin or other suitable order. If no runnableexecution context 38 is found, then the available virtual processor 32may then attempt to locate an unrealized task 42 in the workstealingqueues 96 of the current schedule group 90 before searching theworkstealing queues 96 in the remaining schedule groups 90 of scheduler22 in a round-robin or other suitable order.

FIG. 5 is a block diagram illustrating an embodiment of computer system100 which is configured to implement runtime environment 10 includingscheduler 22 where scheduler 22 is configured to schedule executioncontexts for execution by processing resources as described above.

Computer system 100 includes one or more processor packages 102, amemory system 104, zero or more input/output devices 106, zero or moredisplay devices 108, zero or more peripheral devices 110, and zero ormore network devices 112. Processor packages 102, memory system 104,input/output devices 106, display devices 108, peripheral devices 110,and network devices 112 communicate using a set of interconnections 114that includes any suitable type, number, and configuration ofcontrollers, buses, interfaces, and/or other wired or wirelessconnections.

Computer system 100 represents any suitable processing device configuredfor a general purpose or a specific purpose. Examples of computer system100 include a server, a personal computer, a laptop computer, a tabletcomputer, a personal digital assistant (PDA), a mobile telephone, and anaudio/video device. The components of computer system 100 (i.e.,processor packages 102, memory system 104, input/output devices 106,display devices 108, peripheral devices 110, network devices 112, andinterconnections 114) may be contained in a common housing (not shown)or in any suitable number of separate housings (not shown).

Processor packages 102 include hardware threads 16(1)-16(M). Eachhardware thread 16 in processor packages 102 is configured to access andexecute instructions stored in memory system 104. The instructions mayinclude a basic input output system (BIOS) or firmware (not shown), OS120, a runtime platform 122, applications 124, and resource managementlayer 14 (also shown in FIG. 1). Each hardware thread 16 may execute theinstructions in conjunction with or in response to information receivedfrom input/output devices 106, display devices 108, peripheral devices110, and/or network devices 112.

Computer system 100 boots and executes OS 120. OS 120 includesinstructions executable by hardware threads 16 to manage the componentsof computer system 100 and provide a set of functions that allowapplications 124 to access and use the components. In one embodiment, OS120 is the Windows operating system. In other embodiments, OS 120 isanother operating system suitable for use with computer system 100.

Resource management layer 14 includes instructions that are executablein conjunction with OS 120 to allocate resources of computer system 100including hardware threads 16 as described above with reference toFIG. 1. Resource management layer 14 may be included in computer system100 as a library of functions available to one or more applications 124or as an integrated part of OS 120.

Runtime platform 122 includes instructions that are executable inconjunction with OS 120 and resource management layer 14 to generateruntime environment 10 and provide runtime functions to applications124. These runtime functions include a scheduler function as describedin additional detail above with reference to FIG. 1. The runtimefunctions may be included in computer system 100 as part of anapplication 124, as a library of functions available to one or moreapplications 124, or as an integrated part of OS 120 and or resourcemanagement layer 14.

Each application 124 includes instructions that are executable inconjunction with OS 120, resource management layer 14, and/or runtimeplatform 122 to cause desired operations to be performed by computersystem 100. Each application 124 represents one or more processes, suchas process 12 as described above, that may execute with scheduler 22 asprovided by runtime platform 122.

Memory system 104 includes any suitable type, number, and configurationof volatile or non-volatile storage devices configured to storeinstructions and data. The storage devices of memory system 104represent computer readable storage media that store computer-executableinstructions including OS 120, resource management layer 14, runtimeplatform 122, and applications 124. The instructions are executable bycomputer system to perform the functions and methods of OS 120, resourcemanagement layer 14, runtime platform 122, and applications 124described herein. Examples of storage devices in memory system 104include hard disk drives, random access memory (RAM), read only memory(ROM), flash memory drives and cards, and magnetic and optical disks.

Memory system 104 stores instructions and data received from processorpackages 102, input/output devices 106, display devices 108, peripheraldevices 110, and network devices 112. Memory system 104 provides storedinstructions and data to processor packages 102, input/output devices106, display devices 108, peripheral devices 110, and network devices112.

Input/output devices 106 include any suitable type, number, andconfiguration of input/output devices configured to input instructionsor data from a user to computer system 100 and output instructions ordata from computer system 100 to the user. Examples of input/outputdevices 106 include a keyboard, a mouse, a touchpad, a touchscreen,buttons, dials, knobs, and switches.

Display devices 108 include any suitable type, number, and configurationof display devices configured to output textual and/or graphicalinformation to a user of computer system 100. Examples of displaydevices 108 include a monitor, a display screen, and a projector.

Peripheral devices 110 include any suitable type, number, andconfiguration of peripheral devices configured to operate with one ormore other components in computer system 100 to perform general orspecific processing functions.

Network devices 112 include any suitable type, number, and configurationof network devices configured to allow computer system 100 tocommunicate across one or more networks (not shown). Network devices 112may operate according to any suitable networking protocol and/orconfiguration to allow information to be transmitted by computer system100 to a network or received by computer system 100 from a network.

Although specific embodiments have been illustrated and describedherein, it will be appreciated by those of ordinary skill in the artthat a variety of alternate and/or equivalent implementations may besubstituted for the specific embodiments shown and described withoutdeparting from the scope of the present invention. This application isintended to cover any adaptations or variations of the specificembodiments discussed herein. Therefore, it is intended that thisinvention be limited only by the claims and the equivalents thereof.

What is claimed is:
 1. A method performed by a scheduler of a processexecuting on a computer system, the method comprising: detecting that afirst execution context preempted and blocked by an entity other thanthe scheduler in a first critical region while executing on a processingresource of the scheduler, the first critical region is a set ofinstructions in the first execution context whose execution becomescontingent on data corresponding to the processing resource; andensuring that the first execution context resumes execution on theprocessing resource in response to an indication to the scheduler fromthe entity that caused the block indicating the first execution contextbecoming unblocked and without the scheduler providing any knowledge ofthe preemption to the first execution context.
 2. The method of claim 1further comprising: preventing a second execution context from enteringa second critical region on the processing resource subsequent to thefirst execution context blocking and prior to resuming execution of thefirst execution context, the second critical region is a set ofinstructions in the second execution context whose execution becomescontingent on data corresponding to the processing resource.
 3. Themethod of claim 1 further comprising: setting a critical regionindicator corresponding to the first execution context in response tothe first execution context entering the first critical region.
 4. Themethod of claim 3 wherein the first execution context blocks in responseto a block from outside of the scheduler.
 5. The method of claim 4further comprising: clearing the critical region indicator in responseto the first execution context exiting the first critical regionsubsequent to resuming the first execution context.
 6. The method ofclaim 1 further comprising: storing an indicator that identifies theprocessing resource in response to the first execution context blockingin the first critical region.
 7. The method of claim 1 furthercomprising: providing a signal to the scheduler in response to the firstexecution context becoming unblocked.
 8. The method of claim 1 whereinthe first critical region executes to select a second execution contextfor execution on the processing resource.
 9. The method of claim 1wherein the processing resource includes a virtual processor that mapsto a hardware thread.
 10. A computer readable storage medium storingcomputer-executable instructions that, when executed by a computersystem, perform a method comprising: entering a critical region of afirst execution context executing on a first processing resource of ascheduler in a process of the computer system, the critical region is aset of instructions in the first execution context whose executionbecomes contingent on data corresponding to the first processingresource; setting a first indicator corresponding to the first executioncontext in response to entering the critical region; blocking inresponse to a preemption and block by an entity other than the schedulersubsequent to setting the first indicator; and ensuring that the firstexecution context resumes execution on the first processing resource inresponse to an indication to the scheduler from the entity that causedthe block indicating the first execution context has become unblockedand without the scheduler providing any knowledge of the preemption tothe first execution context.
 11. The computer readable storage medium ofclaim 10, the method further comprising: storing a second indicator thatidentifies the first processing resource in response to blocking. 12.The computer readable storage medium of claim 11, the method furthercomprising: exiting the critical region of the first execution contextsubsequent to resuming execution of the first execution context on thefirst processing resource; and clearing the first indicator in responseto exiting the critical region.
 13. The computer readable storage mediumof claim 12, the method further comprising: setting the first indicatorby incrementing the first indicator; and clearing the first indicator bydecrementing the first indicator.
 14. The computer readable storagemedium of claim 10, the method further comprising: blocking in responseto the first processing resource not being available to enter thecritical region prior to entering the critical region.
 15. The computerreadable storage medium of claim 10, the method further comprising:moving to a second processing resource in response to the firstprocessing resource not being available to enter the critical region.16. A method performed by a scheduler of a process executing on acomputer system, the method comprising: identifying a first executioncontext that preempted and blocked by an entity other than the schedulerin a first critical region while executing on a processing resource ofthe scheduler, the first critical region is a set of instructions in thefirst execution context whose execution becomes contingent on datacorresponding to the processing resource; and resuming execution of thefirst execution context on the processing resource in response to anindication to the scheduler from the entity that caused the blockindicating the first execution context has become unblocked and withoutthe scheduler providing any knowledge of the preemption to the firstexecution context and prior to allowing a second critical region of asecond execution context to execute on the processing resource, thesecond critical region is a set of instructions in the second executioncontext whose execution becomes contingent on data corresponding to theprocessing resource.
 17. The method of claim 16 wherein the firstcritical region holds a lock.
 18. The method of claim 16 wherein thefirst execution context blocks in response to a page fault.
 19. Themethod of claim 16 further comprising: preventing the execution contextfrom entering the second critical region on the processing resourcesubsequent to the first execution context blocking and prior to resumingexecution of the first execution context.
 20. The method of claim 16wherein the processing resource includes a virtual processor that mapsto a hardware thread.